In a database management system, data is often maintained and presented to end users as views. Views are derived data that can be stored (materialized) in a database for subsequent querying. The base relations (or tables) of the database are used to compute views. However, recomputing views after updates to the base relations can be very expensive.
Numerous strategies have been derived for handling the maintenance of materialized views. Generally, two; basic approaches are used. The first and most obvious is to rematerialize the view using the data of the base relations which compute it. The second method is to maintain a differential file, or set of tables, and process only changes to the base relations since the last view update.
View maintenance has been studied extensively in the literature for various view definition languages, e.g., Select-Project-Join (SPJ) views, views with multiset semantics, views with grouping/aggregation, and recursive views; for various types of updates, e.g., insertions, deletions, modifications, to the database relations; and for modifications to the view definition itself.
The problem of determining which additional views to materialize, in order to reduce the cost of view maintenance, has been studied in the context of rule-based systems based on the RETE, TREAT and A-TREAT models. These models are based on discrimination networks for each rule (view); the RETE model materializes selection and join nodes in the network, while the TREAT model materializes only the selection nodes. The A-TREAT model chooses (for a fixed discrimination network) nodes to materialize using a selectivity based heuristic. Some have chosen a discrimination network and nodes to maintain, using "profitability" heuristics. Similar issues have been studied earlier in the context of maintaining integrity constraints. However, none of the above has explored how to choose the best set of materialized views (the best choice of discrimination network and the nodes to be maintained in it) in a truly cost-based manner.
The supplementary relations used in the bottom-up evaluation of recursive queries can also be viewed as additional materialized views that are maintained (during query evaluation) in order to efficiently maintain the view relations defining the original query. However, supplementary relations are introduced as part of a query rewriting step and do not take cost into consideration. They may be introduced when they are not required for efficient view maintenance, or not be introduced even when they are useful for efficient view maintenance.
None of the prior art methods solve the problem of reducing the cost of maintaining a materialized view after a change to the database by materializing additional views, or teach a method for finding the best set of views to materialize.